這幾天也剛好講到 Retro 的相關內容，不仿就來分享一下，

要如何藝術性的提一些開發上的小毛病

其實在運行了五年的敏捷之路上，
我們可以將 團隊敏捷 實踐到經的起考驗
也盡可能地將 專案敏捷 做到問心無愧
但唯獨個人敏捷，講真的無法落實到每個人心裡
詳情可以參考 D20 - 團隊敏捷、專案敏捷以及個人敏捷

團隊成員來來去去
我們沒辦法期待每個人都是經驗老道的工程師
且即便是經驗老道的工程師，也是可能會有處理不好的情況
這邊就以一個案例事件來說明吧～

每個團隊都有每個團隊各自的開發風格

團隊是這樣，個人更是如此。

那是一次預估與實際相差很多案例，但比較冤枉的部分在於這張單本身也不是什麼很難的開發
遇到的狀況是:
local api 沒有測試過就直接丟到 APIM
所以後來 call 不到 API 時直以為是 APIM 的問題

想當然爾，這件事情當然會在 Retro 提出。

我 : 我希望 之後大家再開發完可以自己 local 先測試過一遍，這樣可以少走一點冤枉路。
同事 A : 可是這次不是這個問題而已，後面還有發現之前誰寫的程式有寫錯，所以才查修比較久。

等等，我也只是提了一個很基本的東西吧...

在這個 Case 中，我後來心裡面復盤幾種做法(雖然當時心中萬馬奔騰，稍後也會說明當時的做法)

1.可以稍微嚴肅的說，這很基本吧，我覺得我們團隊要做到。

這樣或許在短時間內有效(但也僅此於或許)，但可以篤定的是時間久一點後，同樣的問題應該八九成還會出現。
況且這樣應該會得到一些隱藏的聲音，例如：
"空降仔，懂什麼？"
"我們團隊以前都是怎樣怎樣做"
險些得不償失

2.好吧放棄溝通，那就算了，但不要下次還讓我看到類似的錯誤。

這個方向從標題上來就很明顯的告訴還在理智線上的我們，不優。
但為何要在文內提出呢？
主要就是要跟諸君互相提醒，此法為最不靠譜的方式。
切記，引此為戒。

3.順應同事 A 所討論的問題點，繼續討論

在討論時，一樣專注於眼前所指的新議題
但在最後可以補充說明
"如果以後查修超過了預計時間的一半，且還沒有頭緒的話，請找 Master 協助"

盡量地避免下次有類似案件發生，如果發生則可以提早提供協助
並就在該次的 retro 再次提出這個 issue 來討論

畢竟講太多還不如自己親身體驗了 & 且希望他們會有所收穫 (這句則來自我主管某次 唸 提點我的內容~)

唉
容許我再嘆一口氣
不過這次的案件真的讓我更加操心的，不是同事 A 的推託
而是在場其他六七位工程師的事不關己
沒有任何一人出來附和一句

local 先測過一次，也是滿合理的吧？

不過就慢慢來吧，團隊需要時間抓節奏，我也是如此～

參考資料：
無